\chapter{Programació}
\section{Objectiu de l'aplicació}
L'objectiu de l'aplicació és ser capaç de crear xarxes privades virtuals que no depenguin de cap servidor central, superar els routers NAT i proporcionar una baixa latència.

L'aplicació d'aquest projecte s'ha d'executar com un servei i proveir només una interfície virtual de xarxa. Per tant l'usuari no disposa de cap interfície gràfica, però els missatges de l'aplicació queden guardats en un fitxer al disc per tal de ser consultats en cas necessari.
Tant la gestió dels certificats com la obtenció del llistat inicial de nodes coneguts (també pot ser només un sol node) no formen part de l'aplicació i són tasques de gestió que s'han de realitzar manualment.

\subsection{Funcionament de l'aplicació}
L'aplicació d'aquest projecte, en arrancar, es posa en contacte amb els nodes que té prèviament configurats com a coneguts. Per cada node s'intercanvia la informació necessària per tal de crear el canal segur i poder-se identificar i enrutar els paquets. Per tal que el NAT no tanqui el port d'entrada, cal que l'aplicació no pari d'enviar paquets a tots el nodes. Aquests paquets es poden aprofitar per informar dels altres nodes coneguts, per així garantir una malla completament connectada (veure figura \ref{F:vpn-fullymeshed}).
\begin{figure}[htb]
\centering
\includegraphics[width=0.5\textwidth]{images/vpn-fullymeshed}
\caption{Topologia d'una VPN mallada completament connectada}
\label{F:vpn-fullymeshed}
\end{figure}

Una vegada creada la malla l'aplicació ja pot enrutar directament a cada node el tràfic que li correspon, sense haver de passar per cap altre node i permetent així una baixa latència. Per evitar afegir més capçaleres de les necessàries (\emph{overhead}) l'aplicació enviarà directament els paquets IP enlloc de les trames Ethernet.

\section{Disseny del protocol}
L'objectiu a nivell de seguretat és que tots els nodes puguin realitzar els túnels garantint els serveis criptogràfics del xifrat, l'autenticació i el no repudi. De manera que cada node té la certesa d'estar entregant la informació directament al destí indicat, sabent que cap altre pot estar ni llegint ni manipulant. Els altres nodes també tenen la mateixa certesa de rebre la informació de l'origen indicat.

\subsection{Enrutament segur}
Per assolir aquest objectiu juntament amb el de la baixa latència s'han de realitzar connexions directes entre tots els nodes, i no es poden realitzar agregacions de nodes com típicament es fa en xarxes \keyword{P2P}{Peer to peer} mitjançant nodes \emph{relay}. Fer agregacions posaria la informació en mans d'altres membres de la VPN, els quals no tenen perquè ser de confiança pels dos interessats en la comunicació. També és necessari un mecanisme de validació de les rutes que cada node ofereix (o comparteix), de manera que cap node no pugui canviar l'adreça IP per una que pertanyi a un altre node. Aquesta última necessitat si no es vol dependre de cap servidor \emph{mediator} (que faci de DHCP) obligarà a fixar un adreçament IP estàtic.

Per tant el primer que cal establir és el funcionament de l'adreçament IP. Per a fer-ho es contemplen dues possibilitats: la utilització d'un adreçament que es calculi a partir dels certificats o la incrustació de l'adreçament dins d'algun camp dels certificats.
La primera opció consisteix en definir una distribució de direccions IP, en la que a partir d'un certificat es pugui assignar una única IP. Això facilita la generació de certificats ja que es poden utilitzar certificats genèrics, però en canvi es corre el risc de que l'algoritme esmentat tingui col·lisions i per tant hi hagi conflictes d'IPs compartides. Per seguretat s'optarà per la segona opció malgrat que aquesta sigui més costosa pels administradors dels certificats. Aquesta consistirà en utilitzar algun camp dels certificats per emmagatzemar les polítiques d'assignació d'IPs de forma que els administradors de la VPN la validin al signar el certificat des de la \keyword{CA}{Certificate Authority (per més informació consultar l'annex \refannexdesc{})}.

Després d'examinar els camps de les extensions x509v3 per a certificats, es va trobar una entrada anomenada \emph{nameConstraints}. Aquesta entrada permet definir múltiples tipus de permisos (tant de permetre com d'excloure, veure exemple a la taula \ref{T:nameconstraints} o \cite{nameconstraints}).
\begin{table}[htb]
\begin{center}
\begin{minipage}[htb]{0.6\linewidth}
\footnotesize
\begin{verbatim}
nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
nameConstraints=permitted;email:.somedomain.com
nameConstraints=excluded;email:.com
\end{verbatim}
\end{minipage}
\caption{Exemples de x509v3 nameConstraints}
\label{T:nameconstraints}
\end{center}
\end{table}

Per a aquesta aplicació només es farà ús dels permisos de tipus IP. D'aquesta manera és la CA l'encarregada d'assegurar-se que no validi cap certificat amb una IP ja assignada prèviament, així com també de mantenir un registre de les IPs assignades.

Pel disseny del protocol es necessita un identificador únic per cada node. Es va pensar i valorar per a aquesta aplicació les següents opcions:
\begin{itemize}
\item La IP i port del node
\item La IP pública i port del node
\item Agrupació de IPs i ports (locals i públics)
\item Xarxes que publica el node
\end{itemize}
La utilització de la IP i el port no és informació suficient degut a l'existència de xarxes privades i públiques. %també els NAT simètrics no donen el mateix port per a tots els hosts remots on es connecti un mateix node.
La utilització de la IP pública per aquesta tasca no és valida ja que deixa de ser única si hi ha dos nodes al costat privat abans d'un NAT. Aquests dos en trobar-se es pensaran que són nodes diferents dels que coneixen amb IP pública.
La utilització de l'agrupació de IPs i ports tant locals com públics sembla prou vàlida, però de vegades s'utilitza un NAT per ajuntar diferents subxarxes de mateix identificador de xarxa.
Les xarxes que publica o ofereix un node és una informació validada per la CA i no pot ser repetida per cap altre node de la VPN. És per això que aquesta última opció serà la utilitzada alhora d'identificar els nodes.

\subsection{Transport segur} %UDP+DTLS
Pel que fa a la informació a transportar, el protocol IP està dissenyat per un medi hostil on els paquets es desordenen o es perden, però l'ús de TCP permet oblidar-se d'aquest medi ja que s'encarrega de l'ordenació i de la recuperació de les pèrdues. Degut a que la majoria de comunicacions utilitzen TCP, una VPN transmetrà majoritàriament paquets TCP encapulats dins del protocol que utilitzin pel transport.
En el cas d'utilitzar una VPN sobre TCP i haver-hi congestió a la xarxa, aquesta provocaria la pèrdua dels paquets de la connexió de la VPN i per tant també dels paquets TCP que hi són encapsulats. Com a conseqüència, les dos piles (\emph{stacks}) de TCP reenviarien els paquets perduts de forma que la xarxa encara es saturaria més, tenint cada cop més paquets iguals retransmetent-se.
El protocol IP permet enviar paquets sense control de pèrdues mitjançant UDP, aquest protocol és el que la majoria de VPNs intenten utilitzar per millorar l'eficiència en el cas explicat anteriorment. A més a més no  perjudica en cap mesura, ja que com s'ha dit el protocol IP que va dins de la VPN està dissenyat per un medi amb pèrdues.
El programari de VPNs es complica ja que malgrat sembli que UDP sigui la solució no hi ha implementacions conegudes de capes de seguretat sobre UDP. És per això que la majoria d'elles opten per implementar els seus protocols propis de seguretat.

Malgrat no haver-hi implementacions de protocols de seguretat conegudes sobre UDP, es decideix no utilitzar el TCP i buscar intensament alguna implementació el més segura possible o fins hi tot a poder ser estàndard. Finalment es troba un protocol del 2004 basat en TLS, que van dissenyar N. Modadugu i E. Rescorla de la universitat d'Stanford, anomenat \keyword{DTLS}{Datagram Transport Layer Security} i més tard el 2006 va esdevenir el RFC~4347~\cite{rfc4347} del IETF. A l'annex \refannexpapers{} es pot veure el \emph{paper} inicial que descriu el protocol. El mateix equip va treballar en una variant del DTLS \cite{rfc-dtls-short} (l'esborrany RFC ha caducat i es diu \emph{Extensions for Datagram Transport Layer Security (TLS) in Low Bandwidth Environments}) per estalviar bits en les capçeleres DTLS per a entorns amb poc ample de banda. Proposaven treure els camps repetits a cada \emph{record} de TLS i DTLS que segons ells no són necessaris. Degut a que aquesta variant no va tenir massa èxit i no va esdevenir RFC, en aquest projecte es farà ús del DTLS que descriu el RFC~4347~\cite{rfc4347}. Aquest protocol es troba implementat en les versions més recents de la llibreria OpenSSL i és la implementació que s'ha decidit utilitzar.

\subsection{Conclusions}
Peter Gutmann va analitzar nombroses aplicacions VPN i en va descriure les nombroses errades de disseny dels protocols de seguretat. L'error que remarca és que la majoria d'elles volien simplificar els estàndards segurs ja que són complicats, però conclou que un protocol segur en la seva totalitat és complexe (veure \cite{latm-metzdowd}: a l'annex \refannexmail{} es troba l'e-mail on s'exposa el seu anàlisi).
Per tant la opció de crear un protocol de seguretat propi queda descartada i s'escull la utilització d'un protocol existent i segur com el DTLS, amb el valor afegit de ser un protocol estàndard.

Per acabar la secció, i com a curiositat, a l'annex \refannexmail{} (veure \cite{deq-metzdowd}) hi ha una conversa d'e-mails explicant què passa quan dins d'una VPN hi traspassen dades xifrades externament, com per exemple una connexió \keyword{HTTPS}{Hypertext Transfer Protocol over SSL}. En aquest escenari la informació seria xifrada 2 cops. Si coincidissin múltiples factors, el xifratge resultant podria esdevenir menys segur. Però no hi ha cap implementació que ho tingui en compte ja que la probabilitat de que coincidissin es molt baixa, així que tampoc no es tindrà en compte en aquest programari.

\section{Especificació del protocol}
%Fragmentació a quin nivell.
Les VPN encapsulen tràfic IP dins del protocol IP, de manera que la màxima informació que poden contenir els paquets IP encapsulats és menor. El protocol definit per donar seguretat permet tant el xifratge com la compressió, i això complica el càlcul de la màxima informació que poden contenir els paquets; és per aquest motiu que en primera instància es forçarà que la fragmentació dels paquets la faci el sistema operatiu i els \emph{routers} d'entremig, per tant no s'implementarà cap fragmentació dinàmica dins del programa. En el futur la implementació de la fragmentació dinàmica dins del programa es faria seguint l'estàndard de IP, i d'aquesta manera seria transparent al protocol del programa.
\begin{table}[htb]
\begin{center}
\scriptsize
\begin{tabular}{|c|p{0.0625\linewidth}|p{0.0625\linewidth}|p{0.12\linewidth}|p{0.045\linewidth}|p{0.21875\linewidth}c|}
\hline
bits & \centering 0--3 & \centering 4--7 & \centering 8--15 & \centering 16-18 & \centering 19--31 & \\ \hline \hline
0 & \centering Version & \centering HLen & \centering ToS & \multicolumn{2}{|c}{Total Lenght} & \\ \hline
32 & \multicolumn{3}{|c|}{Identification} & \centering Flags & \centering Fragment Offset & \\ \hline
64 & \multicolumn{2}{|c|}{TTL} & \centering Protocol & \multicolumn{2}{|c}{Header Checksum} & \\ \hline
96 & \multicolumn{5}{|c}{Source Address} & \\ \hline
128 & \multicolumn{5}{|c}{Destination Address} & \\ \hline
160 & \multicolumn{5}{|c}{\em Options (Optional)} & \\ \hline
=0 & \multicolumn{5}{|c}{Data} & \\
+32 & \multicolumn{5}{|c}{\ldots} & \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Packet IPv4}
\label{T:ippkt}
\end{center}
\end{table}
Per evitar afegir més capçaleres (\emph{overhead}) en aquests paquets, ja que són els més importants i freqüents, l'aplicació enviarà directament els paquets IP sense afegir cap capçalera ni identificador (veure taula \ref{T:ippkt}).

Els altres paquets, considerats d'ús exclusivament intern, fan la funció de senyalització de la VPN.
\begin{table}[hbt]
\begin{center}
\scriptsize
\begin{tabular}{|c|p{0.0625\linewidth}|p{0.0625\linewidth}|p{0.125\linewidth}|p{0.25\linewidth}c|}
\hline
bits & \centering 0--3 & \centering 4--7 & \centering 8--15 & \centering 16--31 & \\ \hline \hline
0 & \centering 0000 & \centering 0001 & \centering Pkt ID & \centering Total Lenght & \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Capçalera Packet Intern}
\label{T:inpkt}
\end{center}
\end{table}
Tal com es veu en la taula \ref{T:inpkt}, aquests tenen un format que està inspirat en els 4 primers bytes de la capçalera IP, i es poden diferenciar pel primer byte que en IP defineix la versió del protocol i la longitud de les capçaleres (HLen). El tercer byte, que en IP està destinat a \keyword{ToS}{Type of Service}, en els paquets de senyalització servirà per definir el tipus de paquet intern.
Els tipus de paquets són: paquets \emph{identification} (ID), paquets \emph{identification acknowledgment} (ID ACK) i paquets \emph{keep alive} (KA). El seu ús dins de la comunicació es mostra en la figura \ref{F:dia-pktflow} i s'expliquen a continuació.
\begin{figure}[htb]
\centering
\includegraphics[scale=0.5]{images/dia-pktflow}
\caption{Diagrama de flux de la comunicació}
\label{F:dia-pktflow}
\end{figure}
\subsection{Paquet Identification}
Els paquets \emph{Identification} (ID) descriuen al node que l'envia. Per descriure'l s'envien els següents blocs d'informació:
\begin{itemize}
\item Xarxes que publica el node: fa d'identificador del node.
\item Agrupacions de IP i port: altres vies per comunicar-se amb el node.
\end{itemize}
En el paquet (taula \ref{T:pktid}), primer s'envien el número d'entrades que contenen els dos blocs d'informació, tot seguit s'envia el primer bloc amb totes les xarxes que el node publica i desprès, en el segon bloc, totes les agrupacions de IP i port.
Aquest tipus de paquet utilitza com a identificador de paquet intern el valor hexadecimal $0x00$.
\begin{table}[htb]
\begin{center}
\scriptsize
\begin{tabular}{|c|p{0.0625\linewidth}|p{0.0625\linewidth}|p{0.125\linewidth}|p{0.25\linewidth}c|}
\hline
bits & \centering 0--3 & \centering 4--7 & \centering 8--15 & \centering 16--31 & \\ \hline \hline
0 & \centering 0000 & \centering 0001 & \centering 0x00 & \centering Total Lenght & \\ \hline
32 & \multicolumn{2}{|c|}{\# Networks} & \centering \# IP-Ports & \\ \cline{0-3} \noalign{\vskip 2pt} \hline
48 & \multicolumn{4}{|c}{Network IP} & \\ \hline
80 & \multicolumn{4}{|c}{Network Netmask} & \\ \hline
112 & \multicolumn{4}{|c}{\ldots} & \\ \hline
144 & \multicolumn{4}{|c}{\ldots} & \\ \cline{0-5} \noalign{\vskip 2pt} \cline{0-5}
=0 & \multicolumn{4}{|c}{Host IP} & \\ \hline
+32 & \multicolumn{3}{|c|}{UDP Port} & \\ \hline
+48 & \multicolumn{4}{|c}{\ldots} & \\ \hline
+80 & \multicolumn{3}{|c|}{\ldots} & \\ \cline{0-3}
\end{tabular}
\end{center}
\begin{center}
\caption{Paquet ID}
\label{T:pktid}
\end{center}
\end{table}
\subsection{Paquet Identification Acknowledgment}
Els paquets \emph{Identification Acknowledgment} (ID ACK) confirmen haver rebut el paquet ID. El paquet (taula \ref{T:pktidack}) no conté cap més informació addicional tal com es pot veure en la seva estructura.
Aquest tipus de paquet utilitza com a identificador de paquet intern el valor hexadecimal $0x01$.
\begin{table}[htb]
\begin{center}
\scriptsize
\begin{tabular}{|c|p{0.0625\linewidth}|p{0.0625\linewidth}|p{0.125\linewidth}|p{0.25\linewidth}c|}
\hline
bits & \centering 0--3 & \centering 4--7 & \centering 8--15 & \centering 16--31 & \\ \hline \hline
0 & \centering 0000 & \centering 0001 & \centering 0x01 & \centering 0x04 & \\ \hline
\end{tabular}
\end{center}
\begin{center}
\caption{Paquet ID ACK}
\label{T:pktidack}
\end{center}
\end{table}
\subsection{Paquet Keep Alive}
Els routers NAT s'utilitzen generalment per compartir una mateixa IP entre màquines diferents. El router desa cada connexió en memòria per tal de reutilitzar els mateixos paràmetres en travessar més dades per la connexió. Tots els routers NAT assignen un temps de vida a la informació guardada en memòria i el renoven a mesura que circulen dades de la connexió. En el moment que caduca el temps de vida, la connexió es perd sense que cap dels participants se n'adonin, és per això que és important assegurar-se de que el router no arribi a esgotar aquest temps de vida.

El paquet \emph{Keep Alive} (KA) té dos objectius: mantenir el canal obert i ajudar a mallar la VPN.
El primer objectiu fa que enviar aquest paquet només sigui necessari quan no s'ha enviat cap altre informació al canal, en canvi el segon objectiu fa que sigui necessari enviar-lo cada cert temps. D'aquesta manera es defineixen dos temps configurables que s'anomenaran $t_{min}$ i $t_{max}$. La política d'enviament resultant consisteix en enviar un paquet KA cada $t_{min}$ des de l'últim paquet transmès pel canal, i en cas de no haver-se enviat cap paquet d'aquests durant $t_{max}$ es forçaria l'enviament malgrat no fos necessari pel primer objectiu.

\begin{table}[htb]
\begin{center}
\scriptsize
\begin{tabular}{|c|p{0.0625\linewidth}|p{0.0625\linewidth}|p{0.125\linewidth}|p{0.25\linewidth}c|}
\hline
bits & \centering 0--3 & \centering 4--7 & \centering 8--15 & \centering 16--31 & \\ \hline \hline
0 & \centering 0000 & \centering 0001 & \centering 0x02 & \centering Total Lenght & \\ \hline
32 & \multicolumn{2}{|c|}{\# Peers} \\ \cline{0-2} \noalign{\vskip 2pt} \cline{0-3}
40 & \multicolumn{2}{|c|}{\# Networks} & \centering \# IP-Ports & \\ \hline
56 & \multicolumn{4}{|c}{Network IP} & \\ \hline
88 & \multicolumn{4}{|c}{Network Netmask} & \\ \hline
120 & \multicolumn{4}{|c}{\ldots} & \\ \hline
152 & \multicolumn{4}{|c}{\ldots} & \\ \hline
=0 & \multicolumn{4}{|c}{Host IP} & \\ \hline
+32 & \multicolumn{3}{|c|}{UDP Port} & \\ \hline
+48 & \multicolumn{4}{|c}{\ldots} & \\ \hline
+80 & \multicolumn{3}{|c|}{\ldots} & \\ \cline{0-3} \noalign{\vskip 2pt} \cline{0-3}
=0 & \multicolumn{2}{|c|}{\ldots} & \centering \ldots & \\ \hline
+16 & \multicolumn{4}{|c}{\ldots} & \\ \hline
+48 & \multicolumn{4}{|c}{\ldots} & \\ \hline
=0 & \multicolumn{4}{|c}{\ldots} & \\ \hline
+32 & \multicolumn{3}{|c|}{\ldots} & \\ \cline{0-3}
\end{tabular}
\end{center}
\begin{center}
\caption{Paquet KA}
\label{T:pktka}
\end{center}
\end{table}
Per tal de complir el segon objectiu fa falta afegir informació dels altres nodes de la VPN dins del paquet, la informació necessària és la mateixa que la continguda al paquet ID.
En el paquet (taula \ref{T:pktka}), primer s'envia el nombre de nodes que es descriuran. Tot seguit s'enviara el mateix contingut dels paquets ID un darrera l'altre.
Per tant aquest paquet, porta la informació suficient per a poder establir una connexió amb cada un dels nodes que descriu tot mantenint el canal obert pels routers NAT, fent així la funció de \emph{hole punching} (aquest concepte es troba definit en un \emph{paper} \cite{p2p} a l'annex \refannexpapers).
Aquest tipus de paquet utilitza com a identificador de paquet intern el valor hexadecimal $0x02$.

\section{Arquitectura del programa}
L'arquitectura del programa, com es veu en la figura \ref{F:dia-app}, es separa entre l'adaptador virtual i el servidor UDP.
\begin{figure}[htb]
\centering
\includegraphics[width=0.5\textwidth]{images/dia-app}
\caption{Diagrama de processos de la aplicació}
\label{F:dia-app}
\end{figure}
\label{arch-temp}
Per altre banda hi ha un temporitzador que s'encarrega de llançar els esdeveniments que depenguin del temps, com l'enviament de paquets \emph{Keep Alive} o el reenviament de paquets \emph{Identification}.

Els paquets que les aplicacions envien a través de l'adaptador virtual són enrutats i enviats de servidor UDP a servidor UDP on retornen a un altre adaptador virtual i a la màquina de destí. Aquest dos s'han implementat mitjançant threads i són capaços d'enrutar i xifrar o desxifrar múltiples paquets simultàniament.

Per a la realització d'aquesta aplicació, és necessari programar tots els components del diagrama (figura \ref{F:dia-app}) a excepció del DTLS, on tal com s'ha especificat anteriorment, s'utilitzarà la implementació de la llibreria OpenSSL.

Pel desenvolupament d'aquesta aplicació s'ha escollit el llenguatge C per ser un lleguatge de baix nivell (permetent treballar el més proper possible als bits) i poder optimitzar-la per aconseguir baixes latències. També s'ha decidit utilitzar la llibreria de threads de \keyword{POSIX}{Portable Operating System Interface} per la seva potència i la compatibilitat amb altres sistemes operatius.

L'elecció d'aquest llenguatge juntament amb la utilització de threads ha comportat múltiples dificultats en la gestió dels recursos compartits entre els diferents threads, però el resultat hauria d'aprofitar millor els recursos de les màquines node.

\subsection{Interfície TUN}
L'aplicació fa ús del \emph{driver} genèric TUN/TAP. S'ha escollit aquest \emph{driver} ja que està disponible per la majoria de sistemes operatius i facilitarà la possible futura adaptació de l'aplicació.
El \emph{driver} TUN/TAP és un \emph{driver} de \emph{kernel} d'una targeta de xarxa virtual, i per tant no depèn de cap targeta real física.
Aquest \emph{driver} es separa en dos \emph{sub-drivers}:
\begin{itemize}
\item \emph{Driver} \textbf{TAP} simula una interfície de xarxa Ethernet i treballa amb trames de capa 2 del model OSI.
\item \emph{Driver} \textbf{TUN} simula una interfície de xarxa punt-a-punt i treballa amb trames de capa 3 del model OSI.
\end{itemize}
En aquestes targetes virtuals els paquets enviats pel sistema operatiu al \emph{driver} són passats a l'aplicació que treballa fora del \emph{kernel} i del \emph{driver}. Els paquets que l'aplicació entrega al \emph{driver} són passats directament al sistema operatiu per a ser tractats pel \emph{stack} de protocols del \emph{kernel}.

\begin{figure}[htb]
\centering
\includegraphics[scale=0.5]{images/dia-tunsrv}
\caption{Diagrama de flux del thread TUN}
\label{F:dia-tunsrv}
\end{figure}
El diagrama d'aquesta part de l'aplicació està en la figura \ref{F:dia-tunsrv}.
El primer que fa el node en rebre un paquet de la interfície TUN és comprovar que el paquet provingui d'una adreça IP que els altres nodes reconeguin com a pròpia d'ell, desprès busca el node a qui va destinat i li envia pel canal xifrat. En el cas de no complir algun dels requisits es descarta el paquet sense notificar-ho.

\subsection{Servidor UDP/DTLS}
Tal com s'ha definit anteriorment el servidor UDP utilitza el protocol DTLS. La figura \ref{F:dia-udpsrv} mostra el diagrama d'aquesta part de l'aplicació un cop desxifrat el paquet.
\begin{figure}[htb]
\centering
\includegraphics[scale=0.5]{images/dia-udpsrv}
\caption{Diagrama de flux del thread UDP}
\label{F:dia-udpsrv}
\end{figure}
En arribar un paquet es separa entre paquets IP o paquets interns, després els paquets interns s'identifiquen pel seu identificador de paquet intern separant així entre ID, ID Ack i KA.

Els paquets \textbf{IP} es comproven que vaguin destinats a una adreça IP de les que s'han anunciat inicialment amb els paquets ID. Es comprova també que vinguin d'una IP validada de les anunciades pel node de procedència. 

Els paquets \textbf{ID} es comproven que no siguin d'un node ja conegut i que publiquin xarxes d'acord al seu certificat, tot seguit se li retorna un paquet ID Ack. En cas de que no hagi rebut un paquet ID amb anterioritat, se li enviarà també un paquet ID. Finalment s'afegeix el node a la base de dades, excepte en el cas de no complir les condicions inicials que es tancaria la connexió DTLS.

Els paquets \textbf{ID Ack} anoten conforme l'altre node ha rebut satisfactòriament el paquet ID, per poder ser consultat en rebre un paquet ID.

Els paquets \textbf{KA} afegeixen tota la informació dels nodes rebuda a la base de dades de nodes pendents de connectar. Cada cert temps el temporitzador del programa comprovarà aquestes dades i intentarà connectar-se a ells. El temporitzador que manté oberts els ports als routers NAT, aquest s'actualitza cada cop que es rep un paquet vàlid.

\section{Gestió de la VPN}
Tal com s'ha comentat a principis d'aquest capítol, certes tasques són externes al programari creat i s'han de realitzar manualment. D'aquestes tasques, algunes són exclusives de l'administrador de la VPN, però d'altres les ha de realitzar el mateix usuari.
En la figura \ref{F:dia-case} es mostren les diferents tasques necessàries per tal de poder gestionar la VPN. En aquesta figura la part blava fa referencia a tasques de gestió, la groga a comunicacions, la taronja a l'utilització de eines externes i la verda al propi programa creat.
\begin{figure}[htb]
\centering
\includegraphics[width=\textwidth]{images/dia-case}
\caption{Diagrama de casos d'ús}
\label{F:dia-case}
\end{figure}

A continuació s'exposa el procediment que l'usuari ha de realitzar inicialment per preparar l'aplicació:
\begin{enumerate}
\item Aconseguir un certificat firmat i un rang IP.
\item Configurar l'aplicació per utilitzar el certificat i una IP del rang assignat.
\item Demanar la llista de nodes coneguts a algun membre (o a l'administrador de la VPN).
\item Instal·lar la llista de nodes coneguts aconseguida.
\item Arrancar l'aplicació.
\end{enumerate}
Una vegada realitzat aquest procediment inicial l'usuari pot fer ús dels serveis de dins de la VPN. Les pròximes vegades que l'usuari vulgui tornar a accedir a la VPN només necessitarà arrancar l'aplicació.

Com aclariment, seguidament s'explica un exemple del primer pas del procediment anterior (aconseguir el certificat firmat per la CA):
\begin{enumerate}
\item L'\textbf{usuari} demana accedir a la VPN a l'administrador.
\item L'\textbf{administrador} li assigna temporalment una IP.
\item L'\textbf{administrador} informa a l'usuari del procediment per generar una petició de certificat amb la IP assignada.
\item L'\textbf{usuari} genera la petició de certificat amb: la IP assignada, el seu nom, etc.
\item L'\textbf{usuari} s'identifica a l'administrador (mitjançant alguna documentació oficial) i li entrega la petició de certificat.
\item L'\textbf{administrador} comprova la identificació, verificant que està autoritzat a accedir a la VPN.
\item L'\textbf{administrador} li assigna definitivament la IP.
\item L'\textbf{administrador} entrega a l'usuari el certificat firmat per la CA.
\end{enumerate}
